home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / urn / urn-archives / urn-ietf.archive.9611 / 000163_owner-urn-ietf _Thu Nov 14 11:32:08 1996.msg < prev    next >
Internet Message Format  |  1997-02-19  |  4KB
  1. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id LAA24415 for urn-ietf-out; Thu, 14 Nov 1996 11:32:08 -0500
  2. Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id LAA24410 for <urn-ietf@services.bunyip.com>; Thu, 14 Nov 1996 11:32:06 -0500
  3. Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
  4.         id AA20551  (mail destined for urn-ietf@services.bunyip.com); Thu, 14 Nov 96 11:31:25 -0500
  5. Received: from ifi.unizh.ch by josef.ifi.unizh.ch 
  6.           id <00775-0@josef.ifi.unizh.ch>; Thu, 14 Nov 1996 17:30:29 +0100
  7. Subject: Re: [URN] Re: I18N does not belong in URNs
  8. To: moore@cs.utk.edu
  9. Date: Thu, 14 Nov 1996 17:30:27 +0100 (MET)
  10. Cc: stu_weibel@oclc.org, urn-ietf@bunyip.com
  11. In-Reply-To: <199611132012.PAA20767@ig.cs.utk.edu> from "Keith Moore" at Nov 13, 96 03:12:48 pm
  12. Mime-Version: 1.0
  13. Content-Type: text/plain; charset=US-ASCII
  14. Content-Transfer-Encoding: 7bit
  15. Content-Length: 2997
  16. From: Martin J Duerst <mduerst@ifi.unizh.ch>
  17. Message-Id: <"josef.ifi..483:14.10.96.16.30.30"@ifi.unizh.ch>
  18. Sender: owner-urn-ietf@services.bunyip.com
  19. Precedence: bulk
  20. Reply-To: Martin J Duerst <mduerst@ifi.unizh.ch>
  21. Errors-To: owner-urn-ietf@bunyip.com
  22.  
  23. Keith Moore writes:
  24.  
  25. >But when people propose adding I18N support to URNs to make them human
  26. >meaningful, I view this as adding a great deal of extra complexity in
  27. >an attempt to make URNs solve a completely different problem than they
  28. >were designed to solve.  (And given the history of various "information 
  29. >infrastructure" groups at failing to narrow their scope to a problem that's 
  30. >solvable in finite time, I get very nervous.)
  31.  
  32. I have stopped proposing adding i18n support for meaningfulness.
  33. This argument is not necessary. But I think it is necessary that
  34. the same amount of meaningfulness is allowed or disallowed to
  35. users of any language around the globe. This is only guaranteed
  36. by either radically restricting the character set or completely
  37. opening it up.
  38.  
  39.  
  40. >By contrast, when people propose adding I18N support to URNs to allow them
  41. >to incorporate URN-like names that happen to include one or two non-universal 
  42. >characters, I wonder things like "Is it really worth the complexity?"
  43.  
  44. The complexity is low. The only thing you are required to do in
  45. the present proposal is convert between 8-bit and %HH form of URNs
  46. (or normalize mixed forms to one or the other). 8-bit and %HH forms
  47. can easily be distinguished. Conversion is easy. Comparison is easy.
  48. If we change the proposal to say that we only have the %HH form,
  49. then everything is even much more easy.
  50.  
  51. Presentation as a Unicode string with nice characters is an
  52. user interface issue. Either the browser or the OS/Window system
  53. will implement it anyway (to some degree), or you won't do it.
  54.  
  55.  
  56. >and 
  57. >"Which is more important, global scope and transcribability and single 
  58. >encoding or the ability to easily grandfather all URN-like systems?"
  59.  
  60. If we restrict URNs to the %HH form (disallow 8-bit), but still define
  61. how the %HH-encoded octets represent characters, we indeed would get
  62. both. Existing namespaces could easily be grandfathered in a straight-
  63. forward way, and we would have a single, transcribable encoding.
  64.  
  65. Even if we stay with the current syntax proposal, the encoding issue
  66. only gets slightly more complex (see above), and average transcribability
  67. will probably be improved. As I have explained in a previous message,
  68. transcribability is a relative issue. If we look at examples such
  69. as transcribing a Japanese account number on a payment slip to an
  70. URN and type it in, allowing the majority of Japanese users to
  71. do it the way they are used and not forcing them to do namespace-
  72. specific calculations on paper is a big win. This win won't in
  73. any way disadvantage a Western user in this case; it will still
  74. be easier for him/her to try to select the character printed on
  75. the payment slip directly with an point-and-click interface than
  76. to try to figure out its namespace-specific coding.
  77.  
  78.  
  79. Global scope, of course, depends on the interpretation of the word
  80. "global". I would prefer if this would be done in the sense of
  81. Global Diversity and not in the sense of Global Common Denominator :-).
  82.  
  83.  
  84. Regards,    Martin.